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Abstract 

The international character of future manned 
space missions will compel the involvement of 
several international space agencies in mission 
planning tasks. Additionally, the community of 
users requires a higher degree of freedom for 
experiment planning. Both of these problems can 
be solved by a decentralized mission planning 
concept using the so-called "envelope method", 
by which resources are allocated to users by 
distributing resource profiles ("envelopes") 
which define resource availabilities at specified 
times. The users are essentially free to plan their 
activities independently of each other, provided 
that they stay within their envelopes. 

The new developments were aimed at refining 
the existing vague envelope concept into a 
practical method for decentralized planning. 
Selected critical functions were exercised by 
planning an example, founded on experience 
acquired by the MSCC during the Spacelab 
missions D1 and D-2. The main activity 
regarding future mission planning tasks was to 
improve the existing MSCC mission planning 
system, using new techniques. An electronic 
interface was developed to collect all formalized 
user inputs more effectively, along with an 
"envelope generator" for generation and 
manipulation of the resource envelopes. The 
existing scheduler and its data base were 
successfully replaced by an artificial intelligence 
scheduler. This scheduler is not only capable of 
handling resource envelopes, but also uses a new 
technology based on neuronal networks. 
Therefore, it is very well suited to solve the 
future scheduling problems more efficiently. 

This prototype mission planning system was 
used to gain new practical experience with 


decentralized mission planning, using the 
envelope method. In future steps, software tools 
will be optimized, and all data management 
planning activities will be embedded into the 
scheduler. 

Introduction 

The proposed concept and system primarily 
addresses mission planning (of on-board 
operations) for payloads of future manned space 
missions. But they should be applicable to 
system planning and/or to unmanned missions as 
well. Most of the examples and expressions are 
taken from the world of Spacelab or Space 
Station (especially D-2 or APM), and most of the 
mission planning aspects are discussed from the 
MSCC point of view. 

All payload mission planning activities of the 
First German Spacelab Mission D1 (30 October 
to 6 November 1985) and of the Second German 
Spacelab Mission D-2 (26 April to 6 May 1993) 
were performed by DLR at MSCC in the 
function of a (remote) POCC. 

For D1 and D-2 a centralized mission planning 
concept was applied. That means that all payload 
relevant information and requirements were 
collected at MSCC, and each timeline version 
was generated at MSCC exclusively. The user 
community was involved in . the timeline 
preparation (-data base creation or update-) but 
not in the timeline development itself. Up to the 
present, centralized mission planning concepts 
have normally been used for manned space 
missions. Many experiences gained during D-2 1 , 
studies and ideas from NASA 4 , upcoming new 
requirements 3 , and some new (technical) 
capabilities were the drivers for a refined mission 
planning concept and a partially new system. 
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Mission Planning Tasks and Constraints 

The mission planning activities include the 
generation of several versions of pre-mission 
timelines, the timeline replanning during a 
mission, and the preparation of an "As-Flown- 
Timeline" after a mission. 

Mission planning in the context of this paper 
consists of developing the plan for all manned 
and unattended activities on board (e.g. on board 
Spacelab). The plan is written down in a 
document which specifies the times for 
performing the procedures necessary to conduct 
the attended experiments, and further documents, 
such as lists and plots of activity steps, resource 
profiles, and command timelines, which are 
produced as supplementary information needed 
by the control center. The plan from which all 
these documents are derived is called simply the 
"timeline". 

In general, the mission planning consists mainly 
of three different tasks: 

• Collecting and analyzing of information, 
availabilities and requirements 

• Generation of the timeline 

• Production of all necessary outputs and 
documentation. 

The second task -timeline generation- is 
performed in three steps: 

. Event generation (=orbit analysis, genera- 
tion of an attitude timeline, computation of 
event on/off times) 

. Experiment and/or system scheduling 

• Data management (=generation of a data 
flow timeline) 

This short description of a mission planning task 
flow is valid for all payload and system 
spacecraft operations. 

The mission planning team has two main 
interfaces. On one side is the spacecraft (e.g. the 
Shuttle including a spacelab ) with all its 
capabilities and availabilities together with the 
organisations (such as NASA and ESA) which 
offer this spacecraft and determine the operations 
concepts in a set of constraints and rules. On the 
other side are the investigators and their 
representative organizations (=the user commu- 
nity) with their requirements to perform 
experiments or other activities. The mission 
planning team attempts to fulfill the requirements 


as well as possible, according to the availabilities 
and regulations. 

New Requirements 
User Requirements 

In order to optimize the scientific return, the 
users need to do some basic mission planning 
functions outside the control center: 

Instead of providing their inputs in the form of 
FO sheets ( -the generation and update of these 
FO sheets was very time consuming and was a 
major source of errors-), the users should 
provide their experiment requirements and inputs 
in form of computer files which can be 
automatically processed. These files should be 
sent to the mission planning center electronically. 
Furthermore, the user community requires a 
certain flexibility for their own experiment 
planning. They require a certain degree of 
freedom to rearrange their experiment runs 
within given time slots by themselves, instead of 
being tied to an inflexibly fixed experiment 
schedule. 

In addition to the gain of flexibility and 
autonomy, another aspect should be mentioned. 
Some "editing" (=data base entries and updates) 
and "micro-timelining" (^detailed step by step 
experiment configuration) tasks are shifted from 
the control centers to the experiment and 
procedure experts of the user community. 

International Co-operation 
Future manned space missions will require more 
international co-operation. These complex 
missions will generally require a certain 
decentralization of mission planning activities. 
(E.g. ESA requires that all planning activities for 
the APM system and payload will be performed 
in Europe, and that different USOCs (in different 
countries) shall take over some basic mission 
planning tasks.) 

General Operations Aspects 
The distribution of mission planning outputs and 
documentation should be performed 
electronically. This would reduce the reaction 
time to get a response from the investigator. 

Future manned space missions will last longer 
than two weeks. The timelines must be 
developed, generated, and maintained in a shorter 
time frame than before. (For D-2 [duration 10 
days ] the timeline generation process lasted up 
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to three weeks, excluding data base preparation 
but including all documentation .) The Space 
Station operations concept requires a new 
timeline for every time increment, and requires 
the capability of handling mission planning 
activities for multiple increments 
simultaneously 3 . In contrast to centrally planned 
short missions, the upcoming long duration 
missions require that all detailed experiment 
knowledge (necessary for mission planning ) is 
located exclusively in the user team, and not at 
the control center. The number of experiments of 
such a mission is too high, and/or the turn- 
around times of the payload (=the number of 
different experiment facilities) is too short to 
collect all the mission planning information in 
detail at a single point. Therefore an electronic 
interface is necessary, as well as a very fast and 
sophisticated scheduler. 

Most of the software used for mission planning 
purposes during the D-2 project was placed at 
DLR's disposal by NASA Marshall Space Flight 
Center (MSFC). Most of these software tools 
have been in use for many years and they cannot 
fulfill the requirements of a modem, user 
friendly, and sophisticated mission planning 
concept. 

A MSCC-specific problem was that all MSFC 
software was available as executables only. No 
software updates, modifications, or changes were 
possible. For a complex and flexible mission 
planning system, it is necessary that new or 
changed software requirements can be 
implemented as soon as possible. This requires a 
modular software concept, with all the software 
code be available at the control center or, -at a 
minimum- very responsive software main- 
tenance. 

The Concept 

Compared to the D-2 mission, the upcoming 
multi-national space missions will have more 
exchange of information between the different 
space agencies on one side, and between the user 
community and the agencies on the other side. 
The flight crew will also need added flexibility in 
the planning and implementation of longer 
duration operations. Therefore, the era of Space 
Station payload operations requires a reassess- 
ment of traditional modes and methods of 
conducting payload operations 4 . However, a 


(new) concept needs not only new methods, but 
also new hardware and software features, and 
new technologies. 

The Concept for Decentralized Mission Planning 
The Envelope Method is able to support all 
shades of mission operation concepts between a 
totally centrally organized and planned mission 
to a mission planned in a completely 
decentralized process. This proposed mission 
planning concept does not discuss different 
mission operations concepts, but proposes a 
feasible mission planning concept under known 
constraints. 

To begin the discussion of a concept, especially 
the discussion of the Envelope Method, on a 
rational and practical level, some general 
assumptions should be presupposed: 

• The concept shall support a reasonable and 
balanced usage of all available (spacecraft) 
resources. 

• The concept shall lead to a higher degree of 
flexibility and autonomy for the user 
community ( compared to traditional 
( =centralized) methods). 

• The concept shall allow a flexible reaction 
on changing or modifying the spacecraft 
operations concepts. 

• The concept shall permit a control center to 
implement all necessary planning, re- 
planning, and conflict-solving activities 
efficiently. 

• The main rule of the "envelope game" is: Do 
not exceed any value of your assigned 
envelopes! 

The Envelope Method 

All aspects of a flexible and efficient 
decentralized mission planning concept can be 
covered by the so-called "Envelope Method". A 
decentralized mission planning concept enforces 
the Envelope Method (and vice versa). Therefore, 
decentralized mission planning with the envelope 
method is further abbreviated into "the envelope 
concept". 

The resources which are shared by several users, 
can be distributed via resource envelopes. 
Resources include crew time, power, real-time 
data downlink, etc. A resource envelope is a 
time-dependent profile that defines the available 
amount of the resource at a specified time. An 
envelope should be a greater, contiguous block of 
a resource. Each user will get several envelopes, 
one for each resource. A user can plan his 
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activities within his resource envelopes 
independently from the other users. The block 
structure of the envelopes prevents an 
interlocking of the activities of different users. 
Envelopes are updated only by shifting, 
increasing, or decreasing the blocks, not by 
breaking them down into smaller blocks. 
(Resource) envelopes are a very well suited 
means for information exchange between 
different levels of a hierarchical (mission 
planning) organisation structure (E.g.: POIC (at 
MSFC) <=> APM-CC (at MSCC ) <=> 
Experimenter (at USOC) ). 

There are not only advantages to the Envelope 
Concept. The main disadvantage is that the 
efficiency of the resource usage decreases with 
the number of different envelopes, and decreases 
according to the size of the envelopes. The 
number of envelopes depends, on one hand, on 
the number of resources, on the other hand, on 
the number of '73 "-users (see figure 1). The 
efficiency of a decentrally planned timeline will 
never reach that of a centrally planned one 2 . In 
other words, if all sharable resources (such as 
power, crew time, downlink and uplink etc.) are 
split up into several resource envelopes for the 
different users, it is impossible to fully exploit 
each resource and to fill up each unused gap of a 
resource. One can gain a high flexibility and 
autonomy of planning by using the envelopes, 
but one has to pay for this with a decreasing 
resource usage. (For more information see 
"Envelope Concept in detail".) 


£1 


£ 2 


than expected, there will be less chance of 
impacting other experiments than in the case 
where the schedule is tightly packed. 

Mission Planning with the 

Envelope Concept 

Figure 1 describes the (Decentralized) Envelope 
Mission Planning Concept of a three level 
system by the Space Station-APM scenario from 
the MSCC point of view: 

All users generate and update their mission 
planning inputs and deliver them in form of 
requirement profiles to the APM-CC. All inputs 
are then checked against operational constraints 
and integrated into the mission planning data 
base. 

At first cut, the APM-CC develops a timeline 
according to the user requirements and the 
resource availabilities provided by level 1 (11, 
overall mission management or e.g. the POIC) to 
each member of level 2 (22, e.g. the APM-CC). 
(It is assumed that there will be different control 
centers which are responsible for different 
modules of the Space Station.) From this 
timeline, the resource envelopes for level 3 (23, 
the users) are generated and transmitted to the 
users. The users plan their experiments/activities 
independently from each other within their 
assigned resource envelopes.* 

The results are new or changed requirements (in 
form of an updated subtimeline or in form of 
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Figure 1 The MSCC Mission Planning 
Concept (an example of the APM scenario) 


updated requirements) which are returned to the 
APM-CC, where all subtimelines (or 
requirements) are merged into the master 
timeline (or data base). Each user is responsible 


Keep in mind that it is not allowed to the users to exeed 
any envelope value. 


However, a loosely packed timeline is less 
sensitive to the problems which typically occur 
during a mission; if an experiment takes longer 
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for updating his data base input and forwarding it 
to the APM-CC. For each version of the 
timeline, several iterations of this process with 
updated envelopes will be necessary to solve 
upcoming conflicts between different users. 

The APM-CC maintains the mission planning 
data base, the master timeline, and the resource 
envelopes, and checks them against operational 
constraints and for conflicts. All output products 
are produced at the APM-CC. The co-ordination 
with the ll is performed by the APM-CC. 

The above mentioned concept describes roughly 
the pre-mission planning scenario. It could also 
be used for the re-planning during a mission. 
However the (iteration) process has only one 
cycle and the user reaction time and input 
delivery must be fast enough to support the re- 
planning. 

The Envelope Concept in detail 
In general, several variations are possible for 
distributing resource envelopes: 

• Envelopes for all sharable resources: All 
resources used by several users are 
distributed as envelopes. 

• Envelopes for special sharable resources 
only: Only a few resources, which are 
heavily used, are distributed as envelopes. 
After each iteration, additional resources 
which turn out to be strongly in demand, 
and to cause conflicts, can be added to the 
envelope resources. 

• Envelopes for special users only: Only users 
with activities which block out resources for 
a relatively long time (block usage) receive 
resource envelopes. The activities of the 
other users are planned at the APM-CC. 

Having the above mentioned advantages and 
disadvantages in mind, the second option may be 
the most appropriate way to establish the 
envelope concept for mission planning purposes. 

An analysis (of D-2) revealed that most of the 
experiments could be satisfactorily scheduled by 
providing three resource envelopes to each 
experiment. These three main resource envelopes 
may differ from experiment type to experiment 
type, but they all are members of the overall set 
of resource envelopes ( such as crew time, power, 
downlink and uplink capabilities, micro-g 
environment, and other mission dependent 
resources). Resources which are mandatory for a 


successful experiment performance are such main 
resources. ( E.g :: For an earth observation 
experiment the (three) main resources could be 
power, the earth target observation opportunities 
and the reprogramming opportunities. For a 
human physiology experiment the three main 
resources could be crew time, real-time down 
link and uplink capability.) 

Studies 2 > 4 demonstrated that with a decentral- 
ized envelope concept, nearly 80% of the activity 
time (compared with a centrally planned time- 
line) could be achieved. The efficiency may be a 
little bit higher if there are many more iteration 
steps of envelope updating. 

It is not reasonable to distribute all sharable 
resources via envelopes. The resulting timeline 
would have an unacceptably low resource usage. 
If there are too many different envelopes 
available, not only the micro-timelining will 
become very difficult, but also the envelope 
generation (on the control center side) is very 
time consuming. However, distributing only a 
reasonable number of envelopes will unavoidably 
lead to some violations of operational con- 
straints. 

These assertions need a detailed discussion: 

One idea of the Envelope Method is to shift the 
minor conflict solving concerning some heavily 
used resources from the control center to the 
users. But the user is able only to solve conflicts 
concerning his own experiments and concerning 
the distributed (main) resource envelopes. 
Because each resource envelope has the same 
priority for the user, and if all resources and 
constraints were distributed as envelopes, the 
user could get into trouble in the course of his 
internal experiment redesigning. Why? The 
competition (within a certain time frame) of 
some (independent) experiments for different 
resources forces the control center to create 
envelopes with variant shapes for each resource. 
(E.g.: An experiment requires for nearly one 
hour crew time and power, the resource 
envelopes for both resources may not be exactly 
the same.) If this phenomenon is extended to a 
great number of envelopes, it is possible that an 
experiment has a very spatious envelope for each 
single resource, but the intersection of all these 
resource envelopes forces this experiment into a 
completely fixed time frame! 
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It is possible to overcome this pressure of 
competition between different experiments by 
avoiding any parallel scheduling as long as 
possible. But in this case, the overall resource 
exploitation decreases to an unacceptable value. 

The solution is to distribute only the heavily used 
resources via real envelopes, and to consider all 
other resources as free, the first approach. If any 
conflicts concerning these resources arise, the 
resulting conflict management will be done at the 
next higher level (e.g. 12). 

In the above-mentioned example (of the earth 
observation experiment and of the human 
physiology experiment) both experiments have 
different main resource envelopes, but they could 
interfere by any other resource usage. The 
conflict detecting and solving, the rescheduling, 
and the generation/updating of the resource 
envelopes will be one of the principle tasks of a 
control center. (The conflict resolution between 
level and Jt 2 should be done in a similar 

manner, depending on the assigned responsibili- 
ties.) 

T he Concept for Distributed Mission Planning 
The Envelope Concept requires a fast and 
uncomplicated, user friendly information 
exchange between the control center (especially 
the MSCC for the APM control ) and the user 
community. Decentralized mission planning 
gives the user the flexibility and autonomy for 
his own experiment rearrangement. It gives the 
user the possibility to enter all his (mission 
planning) relevant data (real experiment 
requirements or secondary information such as 
experiment procedures etc.) into specific 
electronic data bases. Vice versa, the control 
center is able to electronically distribute all 
outputs and information to the user community. 

The mission planning tasks are performed on 
dedicated mission planning computers. Any 
direct access from outside of the control center to 
these machines is denied, for safety reasons. 
Therefore, a practical electronic information 
exchange concept should be based on commonly 
available networks as the transportation vehicle 
and on commonly used PC's and software as the 
aid to enter or to read data. The recent advances 
in computer technology have made the concept 
of distributed mission planning feasible, because 
all the necessary hardware and software is 
powerful enough, and affordable for everybody. 


and the network connections are no longer a 
problem. 

The Mission Planning gystem 

The following chapter gives an overview of all 
modifications and new developments necessary 
to fulfill the above mentioned requirements and 
concepts. The functions and a rough module 
design of the separate parts are presented, but no 
implementation or software details are men- 
tioned. 

The former D-2 mission planning software was 
mainly NASA-MSFC software. The whole 
system can be divided into four main software 
packages all needing DEC computers with VMS 
as the operating system. (The four software 
packages correspond essentially to the above 
mentioned mission planning tasks: Event 

Generation System (EGS), Experiment Schedul- 
ing System (ESS), Data Management System 
(DMS) and an Interface and Output System con- 
sisting of different software modules which are 
necessary to receive information and to produce 
and forward the output plots, listings, and 
documents. See also figure 2) 

The Event Generation System fF.GS) 

The EGS is an autonomous system necessary to 
prepare event availability profiles for the ESS 
and DMS. The EGS is not affected by the new 
requirements, and is not involved in any new 
concept. Therefore no modifications or updates 
are mentioned here. 

The Requirements Collection System (RCS1 
The MSFC software does not support the 
distributed mission planning as described above. 
Therefore, a completely new software tool had to 
be developed. A first trade-off resulted in the 
decision to use as a basis a commercial relational 
data base with the possibility of defining 
graphical user interface applications. Another 
decision was to implement the RCS on a PC. 
After a market survey, a commercial relational 
data base was found to be the most suitable tool. 
The RCS is a very user-friendly tool, which 
allows the usage of two valiant modes: 

• The first mode allows the control center to 
design a mission dependent questionnaire. 

• In the second mode, the user can enter all 
requirements. 
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The RCS offers the user window menus and 
mouse-sensitive fields to answer all questions; 
naturally it is very easy to change or update the 
parameters. 

The implementation of the RCS could be done in 
three ways: 

• The questionnaire and the resulting 
(requirements) data base can be distributed 
via floppy disc 

• or via networks 

• or the complete RCS is installed at the 
control center, and each user can login 
remotely. 

These three options are not inevitably exclusive. 
Up to now, the first two options are possible. 

The Experiment Scheduling System (ESS} 

The ESS version used for D-2, especially the 
Experiment Scheduling Program (ESP), (and all 
later versions available up to now) is not able to 
support the decentralized mission planning with 
the envelope method. The main weak points of 
ESP are that it is not possible to receive, process 
(compute), or generate detailed profiles* or 
resource requirements, which are given as a 
percentage of the task duration. Additionally, the 
data base concept is problematic, because it is 
not user-friendly and its capacity is limited, the 
handling and the user interface are very 
uncomfortable, and the scheduling philosophy is 
too conservative to support scheduling according 
to the envelope method. (Scheduling according 
to the envelope method corresponds approxi- 
mately to using fuzzy logic.) 

A scheduling tool assessment identified the 
Science Planning Interactive Knowledge 
Environment (SPIKE) as the most suitable and 
fastest scheduling program 1 . 

(SPIKE is an Artificial Intelligence scheduler. It 
was originally designed and developed for 
scheduling Hubble Space Telescope operations. 
The development started in 1987, and SPIKE has 
been operational since 1990. The primary goal 
(of SPIKE ) is to maximize scientific efficiency by 
optimizing the schedule and minimizing the 
violation of scheduling constraints. SPIKE has 
demonstrated its capabilities as a powerful and 
flexible scheduling framework with applicability 
to a wide variety of problems in different 
scientific satellite projects (e.g. EUVE, ASTRO- 
D).) 


)j( 

A profile defines the available and/or requested amount 
of a resource as a step function of time. 


(For detailed information about the SPIKE 
scheduler see 5>6 .) 

ESP (and the corresponding data base) could not 
be exchanged easily with SPIKE. In a first step, 
SPIKE was modified to be used by unexperi- 
enced operators. (The former user interface of 
SPIKE required a detailed knowledge of the 
programming language LISP.) In a second step, 
SPIKE was imbedded into the remaining mission 
planning system. In a third step, SPIKE had to be 
modified to fulfill all operational aspects, 
especially with regard to the replanning 
capabilities 1 , and an interface between the RCS 
and the ESS (mainly SPIKE) had to be 
established. 

The Envelope Manipulation System fF.MSi 
Similar to the RCS, no EMS was available. The 
envelope manipulation task has several 
dependencies. It is influenced by the kind of 
mission and its payload, and by the mission 
operations concept as well as by the experiment 
requirements. Envelope manipulation is done in a 
separate task after the scheduling process. 
Envelope manipulation in detail involves the 
shifting, increasing, decreasing, smoothing, and 
gap filling of a single resource profile. It also 
includes the balancing of resource profiles 
according to the overall (resource) availability. 
Therefore, the EMS needs a very comfortable 
graphical user interface, which allows the 
operator to flexibly imbed the balancing rules as 
external subroutines. 

Because EMS and ESS interact together very 
frequently, it is advantageous to install them on 
the same hardware. 

The EMS was developed with the aid of a 
commercial graphical user interface. The 
subroutines were developed in "C". Conse- 
quently, the EMS is now nearly independent of 
the hardware and the operating system. 

The Data Management System fDMS'i 
The DMS as used for D-2 is still available. The 
DMS could not meet the D-2 requirements; they 
were performed by separate software (especially 
developed for D-2) or by timeline engineers and 
DMS operators. 

For the moment no actions are completed 
concerning a new or changed DMS. 
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Figure 2 The MSCC Mission Planning 
System (an example of the APM scenario) 


Results and Future Aspects 

This mission planning concept and system could 
not be yet verified in a real mission, but the 
complete data base of D-2 is still available, and 
can be used for verifying and tuning the concept 


The Interface and Output Modules 
This tool has only the function of receiving 
and/or forwarding information (to the next higher 
level). This information is in detail mission 
dependent. The single modules are changed or 
updated by requests only. Therefore, a further 
discussion of these modules is not necessary in 
this paper. 


and system in detail. The RCS was tested in- 
house and distributed to some representative ex- 
perimenters to get a feeling for the acceptance, 
and to get proposals for changes or improve- 
ments. The complete envelope scenario was 
simulated in-house with the ESS and EMS. The 
scheduling capabilities, the operator interface, 
and the performance of SPIKE satisfied almost 
all of the requirements. 


Figure 2 summarizes the actual MSCC Mission 
Planning System and gives an impression of how 
all these different (sub-) systems act in 
combination and how they interact with 
externals. Following figure 1, the Mission 
Planning Concept and the information flow is 
reflected. 


Based on this experience, the existing MSCC 
mission planning prototype is able to handle 
the complete envelope concept with all its 
requirements and consequences. 

To bring the mission planning prototype to a 
fully operational system some additional tasks 
remain to be done: 
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One main task is to design a new DMS. Two 
options are possible: either to develop a complete 
new and autonomous system, or to implement 
the missing functions into SPIKE. 

The other main task concerns the interface and 
output modules. All outputs and interfaces are 
highly dependent on actual missions. Therefore, 
several output and interface modules have to be 
changed or to be developed in future. 

(The interface for Shuttle missions already exists 
and will be adapted or upgraded if necessary. 
Interfaces to the ZUP for EUROMIR missions 
must be established. Finally all interfaces (e.g. to 
MSFC and to JSC ) necessary for the operation of 
the APM must be specified and established.) 

For further development of operational concepts, 
mainly concerning mission planning, some 
outcomes of D-2 and from the prototype testing 
should be taken into account. The timeline 
generation premission and the replanning during 
mission should be reorganized. A premission 
timeline should cover just the first one or two 
mission days. The following mission days (or 
crew shifts) will be planned in near real-time 
during the preceding day or shift. All necessary 
inputs for the planning must be available at the 
beginning of such a planning cycle, of course. 

The main advantage of such a concept is that the 
science community is able to react very quickly 
to events. The science people are not forced to 
follow an obsolete preplanned timeline. Also, the 
overall premission timeline generation task could 
be easier. It is no longer necessary to create 
timelines for a whole mission (or great mission 
increments), only the overall resource budgeting 
must be managed. It is obvious that all 
experiment runs which are to be flown on the 
mission must verified, tested, and trained 
premission, but the time when they will be 
performed may be open. 


Abbreviations: 

APM 

Attached Pressurized Module 

DEC 

DIGITAL Equipment Cooperation 

DMS 

Data Management System 

CC 

Control Center 

EGS 

Event Generation System 

EMS 

Envelope Manipulation System 

ESP 

Experiment Scheduling Program 

FO 

Functional Objectives 

GSOC 

German Space Operations Center 

IBM 

International Business Machines 

IDL 

Interactive Data Language 

JSC 

Johnston Space Center 

MSCC 

Manned Space Laboratories Control 
Center 

MSFC 

Marshall Space Flight Center 

RCS 

Requirements Collection System 

SPIKE 

Science Planning Interactive 

Knowledge Environment 

SSCC 

Space Station Control Center 

TL 

Timeline 

ZUP 

Operation Center for Russian Manned 
Space Flights 
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1. Automation 

Operations Automation 

Charles Thomas Boreham 

X- Analyst, A Generic Tool for Automatic Flight Data Analysis 
and Spacecraft Performance Assessment 

Jean-Marc Brenot 

Production and Quality Assurance Automation in the Goddard 
Space Flight Center Flight Dynamics Facility 

K. B. Chapman , C ' M. Cox , C. W. Thomas , O. O. Cuevas , 

R. M. Beckman 

Graphic Server: A Real Time System for Displaying and 
Monitoring Telemetry Data of Several Satellites 
Stephane Douard 

Advanced Technologies in the ASI MLRO Towards a New 
Generation Laser Ranging System 

Thomas Varghese, Giuseppe Bianco 

The Sequence of Events Generator: A Powerful Tool for 
Mission Operations 

Hubertus Wobbe, Armin Braun 
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